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The concept of Traffic Aware Strategic Aircrew Requests (TASAR) combines Automatic 
Dependent Surveillance Broadcast (ADS-B) IN and airborne automation to enable user- 
optimal in-flight trajectory replanning and to increase the likelihood of Air Traffic Control 
(ATC) approval for the resulting trajectory change request. TASAR is designed as a near- 
term application to improve flight efficiency or other user-desired attributes of the flight 
while not impacting and potentially benefiting ATC. Previous work has indicated the 
potential for significant benefits for each TASAR-equipped aircraft. This paper will discuss 
the approach to minimizing TASAR’s cost for implementation and accelerating readiness 
for near-term implementation. 


I. Introduction 

T HE emergence of Automatic Dependent Surveillance Broadcast (ADS-B) and Portable Electronic Devices 
(PED) / Electronic Flight Bags (EFB) offers a rare opportunity to aircraft operators to significantly improve 
their flight operations in the near term. This opportunity is enabled by the ability of aircraft to receive the same 
high-quality traffic surveillance information viewed by Air Traffic Control (ATC) and, as conditions change during 
the flight, to compute re -optimized trajectories that are compatible with nearby traffic. Armed with this information, 
aircrews can more effectively work with air traffic controllers by making flight-optimizing trajectory-change 
requests that consider the proximity of other traffic (i.e., “traffic aware’), thereby proactively mitigating the 
controller’s primary concern of traffic separation and enabling controllers to more frequently approve such requests. 
The result is a win-win situation for users and service providers: (1) users more often receive their desired trajectory 
improvements (whatever they may be), and (2) controllers can provide the desired service to users while saving 
workload associated with fewer problematic or non-approvable requests. 

NASA is developing the concept of Traffic Aware Strategic Aircrew Requests (TASAR) as a near-term flight- 
deck application that leverages onboard computing and ADS-B IN traffic data and other data to provide user 
benefits. * 1 NASA’s work here is motivated by two primary objectives. 

Objective 1: To reduce obstacles for users to achieve near-term direct benefits of ADS-B. The Federal 
Aviation Administration (FAA) is putting into place a surveillance infrastructure based on ADS-B OUT, and it has 
mandated that all aircraft in transponder airspace shall broadcast position data over ADS-B by the year 2020. 2 This 
new “satellite-based” surveillance infrastructure provides direct benefits to the FAA by reducing the cost of 
maintaining expensive radar systems and by providing more accurate surveillance data to air traffic controllers. 
User benefits of ADS-B OUT are less clear, however, and it is commonly accepted by users that ADS-B IN 
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equipment is required to gain measurable benefits through specific applications of air-to-air surveillance. Several 
ADS-B IN applications are in various stages of definition, research, and development, and avionics products are 
already on the market providing limited ADS-B IN capabilities to customers. However, no single application has 
yet emerged to provide a dominating business case for widespread ADS-B IN equipage. NASA and other 
organizations are continuing to develop ADS-B IN applications with the hope that bundles of applications will 
provide sufficient incentive for accelerating ADS-B IN equipage and benefits, eventually leading to a profound total 
impact on airspace operations. 

NASA is developing TASAR in order to provide a low-cost, low-risk avenue for the user community to realize 
early operational benefits of airborne surveillance without the obstacles that typically impede the pace of introducing 
new capabilities. TASAR requires no change to any aspect of the current ATC system. It leverages the existing 
flexibility for pilots to request trajectory changes in-flight, only it significantly improves this process. On the 
ground, it requires no new infrastructure, ATC procedures or tools, or FAA policy changes, all of which could 
otherwise significantly increase the time to initial implementation. On the aircraft, it requires only a computing 
platform with access to certain information and a simple display, with no impact to flight-critical systems. Later 
sections of the paper will discuss how certification and operational approval requirements have been minimized to 
enable users to implement TASAR with relative ease. Most importantly to users, TASAR is a “per-aircraft” 
application, meaning it does not depend on multiple aircraft to be TASAR -equipped for any single aircraft to 
benefit. Indeed, any application that provides full benefits to the first equipped aircraft on its first flight (and every 
flight thereafter) offers a significant incentive for users to be early adopters. 

Objective 2: To accelerate the use of networked cockpit automation for trajectory management. For most 
users, flight optimization occurs in the flight planning and pre -departure clearance process well before the aircraft 
takes off. This process includes determining the optimal flight level based on aircraft performance, weight, and 
forecast winds, and it involves selecting a route consistent with forecast/observed weather and standard ATC filing 
requirements. Once the aircraft is airborne, further flight optimization (if any) falls to the dispatcher or the pilot. Of 
these two company representatives, the one most available to consider improvements to the flight is the pilot (whose 
attention is devoted to their flight). However, with few in-flight replanning tools available, the pilot is not always 
aware that optimization opportunities exist. The aircraft’s Flight Management System (FMS) can provide a 
recommended flight level change as fuel is slowly burned off, but they are not designed to recommend route 
changes due to updated wind or weather forecasts. It is up to the pilot to recognize potential flight improvements 
from experience, often without sufficient information, and to be motivated to make these requests. 

Use of networked cockpit automation fits well with this need for better in-flight replanning. An onboard flight- 
optimization tool has a natural “home court” advantage. It has direct access to data and information from aircraft 
systems and sensors, and the pilot can keep the tool’s optimization objectives updated throughout the flight as 
conditions change. Broadband internet connectivity completes the picture by providing low-cost, real-time access to 
supplemental information on winds, weather, traffic. National Airspace System (NAS) status, and company/dispatch 
inputs. These factors combine to create an environment where any user (from large networked carriers to small 
operators) can do an effective job at optimizing each flight without additional resources devoted on the ground. 

Achieving Objectives 1 and 2, while benefiting users today, should also create an environment in which future 
ADS-B IN applications will more quickly emerge. Some of these envisioned applications of airborne surveillance 
will provide users more autonomy in managing their flights and therefore are expected to provide significantly 
larger user benefits. In addition, with operational use of applications like TASAR, new innovative applications of 
airborne surveillance not previously envisioned are likely to emerge. 

This paper describes the approach to keeping costs as low as possible for operators to adopt TASAR and to 
accelerate readiness for implementation. The paper begins in Section II with a brief description of several parallel 
risk reduction activities underway to achieve these goals. Section III addresses the selection of an appropriate 
computing platform for the TASAR application. Section IV discusses safety implications for certification and 
operational approval. Section V addresses access to the required data during flight. Section VI provides a summary. 

II. Risk Reduction 

Adopting new technology or operational procedures is not a decision taken lightly by aircraft operators. Such 
investments often involve significant upfront expense and the assumption of certain risks of achieving a timely 
return on investment. NASA is pursuing several activities in parallel to reduce the risk to operators in adopting 
TASAR. Each is briefly discussed in this section. Additional detail on some elements is provided in references and 
the following sections of this paper. 
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A. Concept Documentation 

To encourage a shared, detailed understanding of the TASAR concept and to facilitate communication among 
various parties involved in its implementation and approval, NASA produced a Concept of Operations document 
that spells out how TASAR is intended to work within the context of current-day operations. 3 The document 
describes the roles and responsibilities of the controller, aircrew, and other actors within current operations, the 
shortfalls of current user requests that the TASAR concept addresses, and a short description of procedural changes 
under TASAR. A detailed description of the TASAR concept focusing on aircrew interaction with the onboard 
automation and the desired functions/behaviors of the onboard automation is provided in the document and it 
describes the two primary modes of the technology: (1) auto mode that continuously assesses opportunities for 
improving the performance of the flight and (2) manual mode that probes pilot-entered trajectory changes for 
conflicts and performance objectives. The Concept of Operations document discusses the required inputs and 
expected outputs of the automation technology and gives operational scenarios that show the interactions among the 
onboard automation, aircrew, controllers, and other actors. The document also describes potential future evolution 
paths of TASAR. 

B. Preliminary Benefits Assessment 

To provide data for users to assess the merits of TASAR, NASA conducted an initial analysis of user benefits. 4 
The simulation study showed that, on average, an aircraft employing TASAR reduced its travel time by about one to 
four minutes per operation and fuel burn by about 50 to 550 lbs. per operation, depending on the objective of the 
aircrew (e.g., time, fuel, weighted combination), class of airspace user, and aircraft type. The analysis presents 
results such that users could extract specific time and fuel savings based on city pairs similar to their own operation 
and optimization objectives and thus can estimate benefits specific to their business model. These results, presented 
in detail in Reference 4, support the formulation of an internal business case for TASAR. 

C. Assessment of Requirements for Certification and Operational Approval 

NASA conducted several analyses on the requirements to install, certify, and operate a TASAR system. First, an 
analysis of FAA regulations was conducted to determine the appropriate platform for the TASAR application and 
the certification and operational approval requirements for that installation. The analysis determined that a Class 2 
Portable Electronic Device (PED) / Electronic Flight Bag (EFB) provides a reasonable balance between 
functionality and certification cost, given its read-only access to aircraft systems. The TASAR software application 
was determined to best fit the criteria of a Type B application, which does not require costly compliance to software 
development standards. Second, a hazards analysis was conducted and determined that TASAR would likely be 
assessed as having a “No Effect” or at most “Minor Effect” Failure Effects Classification. Following these analyses, 
a draft Project Specific Certification Plan was developed for TASAR and reviewed by Designated Engineering 
Representatives (DER). The DERs raised no concerns with the draft plan, and therefore applicants should anticipate 
no show-stopper issues in the certification and operational approval processes. Sections III and IV will discuss the 
PED/EFB platform and hazards analyses, respectively, in greater detail. 

D. Development of TASAR Software Application 

NASA is currently developing a high-fidelity prototype of the TASAR software application with the goal of 
making it available to users and technology providers. The NASA prototype is the “Traffic Aware Planner” (TAP) 
and runs on a commercial-off-the-shelf Class 2 EFB platform. 5 TAP’s flight optimization and traffic conflict 
management algorithms were originally developed for advanced self -separation research, and these high- 
performance algorithms have been extensively tested and matured for over a decade. TAP continuously scans for 
time- and/or fuel-saving possibilities in three ways: lateral-only route changes, altitude changes, and combination 
lateral/altitude changes. TAP also supports manual mode in which the pilot enters a desired change, and the 
fuel/time impact and conflict prediction results are displayed. This mode will be useful for trajectory change 
requests sent by the aircraft’s dispatcher and for “timing” the actual request for improved likelihood of ATC 
approval. Using a standard navigation database, TAP specifies solutions using published fixes to facilitate voice 
requests. The human-machine interface (HMI) is primarily textual with no display of traffic or own-ship position, 
thus minimizing issues for operational approval. Sample displays of the TAP application’s “Auto” mode are shown 
in Figure 1 . 

For the future, TAP is readily upgradable to take full advantage of a Class 3 EFB environment, including loading 
solutions electronically to the FMS, full use of latitude/longitude waypoints (i.e., not just named fixes), and 
leveraging future data communications with ATC. Making the TAP software application available to the user 
community reduces development risk and delays, and it positions users to take immediate advantage of emerging 
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NextGen capabilities (e.g., ADS-B now, data communications in the coming years). Section V discusses 
considerations for integrating TAP in a live data environment. 



Figure 1 Sample displays of TAP “auto” mode. TAP presents primarily textual information. The graphical display 
provides situation awareness of the proposed trajectory change and does not display traffic or own-ship position. 


E. Pilot Assessment in Simulation and Flight 

NASA is testing TAP functionality and usability with pilots in a high-fidelity human-in-the-loop (HITL) 
simulation and through in-flight assessments on a test aircraft. The HITL simulation experiment, conducted during 
the summer of 2013, involves 12 current airline pilots operating a full-mission Boeing 777 fixed-based simulator on 
a flight through airspace with simulated traffic, dynamic weather, and changing winds. Using the actual TAP-EFB 
integrated system, the study focuses on assessing HMI design and usability, while also validating that pilot workload 
would not be impacted by TAP during nominal and off-nominal conditions. Results will be published in a separate 
paper once data analysis is complete. 

The in-flight assessment, scheduled for September 2013, will ensure that the TAP application works with real- 
world data and is usable by pilots in flight. The TAP-EFB integrated system will be installed in a Piaggio Avanti I 
aircraft equipped with ADS-B IN and broadband internet connectivity providing access to the latest wind forecasts. 
Flights will be operated under Instrument Flight Rules (IFR) in ATC-controlled airspace. A four-staged assessment 
will (1) verify operational data flow and proper processing of the information by TAP, (2) verify TAP’s intended 
functionality, (3) gather data on pilot interactions with TAP in an operational environment, and (4) use TAP to 
support making actual trajectory change requests to ATC. Eight pilots will participate in the flight activity, and pilot 
workload and TAP usability assessments will be compared to HITL simulation results. 

Reports from the HITL simulation and in-flight assessment will be made available to user applicants to serve as 
supplemental artifacts in the certification and operational approval process. These activities should help establish 
the maturity level of the TASAR concept and technology. 

III. TASAR as a PED/EFB Application 

At the core of the TASAR concept is an automation tool to be located onboard the aircraft as a flight-deck EFB 
application for ready access to the pilot. TAP is NASA’s prototype of such a tool. The tool’s primary purpose is to 
advise the pilot when an improvement to the aircraft’s trajectory is available. The software would be installed on a 
computing platform that accesses the required data and provides the pilot ready access to its output, which are 
trajectory-change improvements that the pilot may request of ATC as part of a change request to the current 
clearance. Although one can envision an FMS upgraded with TASAR functionality, this approach does not lend 
itself to the low-cost, near-term solution envisioned to meet the objectives previously discussed. Rather, hosting the 
TASAR software as an EFB application on a PED better aligns with these near-term goals. Meanwhile, future FMS 
systems could be designed with similar functionality. This section of the paper will discuss issues associated with 
TASAR as a PED/EFB application. 
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A. EFB Class Selection 

With the availability of low-cost commercial-of-the-shelf PEDs and their utility to provide increasingly more 
capable software applications to support flight operations, the FAA has developed and continues to update guidance 
information toward the proper use of EFB hardware including PEDs and their hosted software applications for flight 
deck use. 6 The FAA document defines the class of EFB platforms and associated installation (i.e.. Classes 1, 2, and 
3), and it defines the types of software application (i.e.. Types A, B, and C) that may be hosted. As industry 
continues to push for increasing application capabilities being integrated and performed by EFBs, these guidelines 
continue to evolve in terms of the certification and operational approval requirements for the EFB’s ability to 
interact with on-board avionics systems. 

With the goal of developing a near-term application providing early benefits and at relatively low cost, NASA 
has developed TASAR with a read-only interface to on-board avionics systems to obtain the needed information to 
enable its in-flight trajectory replanning capability. Figure 2 provides a functional diagram of TASAR illustrating 
the high-level information flows, including the read-only interfaces to avionics, e.g., ADS-B IN, FMS. 



Figure 2 TASAR Functional Diagram 

The type of EFB implementation that can be approved is dependent on the Failure Effects Classification of the 
application. To determine this classification, the intended function is reviewed and analyzed to determine potential 
operational hazards, failure modes, and safety implications. As will be described in the safety analysis of TASAR in 
detail in Section IV, TASAR is expected to easily meet a Failure Effects Classification of no greater than “Minor” 
and will most likely be “No Effect”. Taking this classification into account, the three Classes of EFBs were assessed 
for their appropriateness to host the TASAR application. 

Class 1 EFBs represent portable installations that do not interface to avionics, i.e., are not connected to aircraft 
systems for data or dedicated aircraft power. Class 1 EFBs represent the low-end of EFB capabilities in terms of 
cost and certification due to their isolation from avionics systems and being limited to hosting non-approved 
software limited to “Minor” Failure Effects Classification or lower. Class 1 EFBs are not appropriate for use for 
TASAR due to TASAR’s requirement for access to avionics for flight data. 

Class 3 EFBs are fully integrated, i.e., installed as part of the flight deck, and are part of the aircraft’s Type 
Certificate (TC), allowing two-way communications of avionics data, e.g., flight plan information to and from the 
FMS. Class 3 EFBs are capable of integrating approved (i.e., certified) software applications. They are thus of 
considerably higher cost due to significant certification and operational approval costs associated with their intended 
use. While it is possible to integrate the TASAR application as a hosted application in a Class 3 EFB (using 

5 

American Institute of Aeronautics and Astronautics 


appropriate partitioning from approved applications already installed in the EFB), this does not represent the lower- 
cost approach envisioned for TASAR. 

Similar to Class 1 EFBs, Class 2 EFBs also consist of portable commercial-of-the-shelf based computers and are 
considered to be PEDs. Class 2 EFB hardware does not require FAA design, production, or installation approval for 
the device and its internal components, and they are not considered to be part of aircraft type design, i.e., not in the 
aircraft TC or Supplemental Type Certificate (STC). Class 2 EFBs are typically mounted and must be capable of 
being easily removed from or attached to their mounts by flight crew personnel. Class 2 EFBs can be temporarily 
connected to an existing aircraft power supply for battery recharging. They may connect to aircraft power, data ports 
(wired or wireless), or installed antennas, provided those connections are installed in accordance with AC 20-173. 7 
Based on the anticipated Failure Effects Classification of “Minor” or “No Effect” and the need for the TASAR 
application to have read-only access to avionics systems, a Class 2 EFB was considered the most appropriate EFB 
platform for TASAR. It should be noted in order to interface a commercial-of-the-shelf PED as a Class 2 EFB will 
require an appropriate Aircraft Interface Device (AID) to serve as an intermediary interface between the PED/EFB 
and the avionics systems, including aircraft power and antenna interfaces to commercially available communication 
data links. 

The following high-level steps are required for installation and operational approval applicable to the TASAR 
Class 2 EFB: 

1. Applicant must obtain approval via TC or STC for initial alterations related to (1) the mounting fixture 
installation, and (2) the installation of power and / or data connectivity. 

2. Manufacturer, provider, or installer must assure via testing that the Class 2 EFB provides interference -free 
operation. If a data transmitter is used to transmit data to the Class 2 EFB, it must be tested to RTCA DO- 
160G, section 21, paragraph M. 8 This ensures that conduction or radiation of emissions do not result in 
interference. 

3. Applicant must obtain TC, STC, or DER approval for installation of antennas that provide data to the EFB, 
e.g., weather data, airspace status information. 

B. EFB Software Considerations 

The FAA has designated EFB software into several categories: Types A, B, and C. Type A applications are 
those paper replacement applications primarily intended for use during flight planning, on the ground, or during 
noncritical phases of flight. Type B applications are intended for use during critical phases of flight or have 
software algorithms that must be tested for accuracy and reliability by applicant. Sample Type B applications are 
(1) display of aeronautical charts viewable electronically and allowing chart manipulation, (2) electronic checklists 
available in all phases of flight, (3) weight and balance calculations/algorithms, and (4) performance calculations. 
These must be tested and proven by the applicant. Type C software applications are found in avionics and include 
intended functions for communications, navigation, and surveillance that require FAA design, production, and 
installation approval. Neither Type A software nor Type B software requires compliance with RTCA/DO-178B 9 , an 
important cost-saving factor. Type C applications do require such compliance and are typically not permitted on 
PED/EFBs as they are for airborne functions with a Failure Effects Classification considered to be a “Major” hazard 
or higher. Of the three software application types, the TASAR application is most closely associated with Type B. 

While TASAR is currently neither a Type A nor Type B application (i.e., not on the FAA’s approved list of 
applications 6 ), it is closely aligned with Type B applications. For instance, TASAR: (1) is intended for use during 
flight planning (in case of TASAR, primarily during the en-route phase of flight), (2) includes variables in the 
information presented based on data-oriented software algorithms (in case of TASAR, using a variety of information 
sources for subsequent processing to determine trajectory-change candidates), and (3) will likely have a Failure 
Effects Classification of no more severe than “Minor”. 

While TASAR is similar to a Type B application, it is anticipated that it actually has a lesser threshold needed 
for approval compared to traditional Type B applications. With TASAR being an optional, supplemental, advisory 
support tool that the pilot or flight crew can use at their discretion (i.e., they can choose to ignore or disable at any 
time for any reason), it in essence represents a Type B “life” application. Appropriate pilot training will further 
ensure that the pilot will not be distracted by TASAR during flight operations. 

C. No Traffic Display 

The TASAR concept is unique among existing and currently envisioned ADS-B IN applications in that it makes 
no use of a traffic display. In fact, because TASAR does not require flight crew awareness of traffic, the NASA 
TAP application was designed to specifically avoid displaying traffic data (including own-ship position) to the pilot. 
This approach reduces the certification and operational approval requirements that may be associated with such 
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depictions and therefore reduces the cost of implementation. Sample displays of the TAP application’s “Auto” 
mode, shown in Figure 1, show how most information is displayed in textual format. As shown in the figure, 
consideration is being given toward a simple graphical display of TAP trajectory recommendations in order to 
provide the pilot with greater situational awareness of these recommendations. An initial safety assessment suggests 
that such a display depiction would not adversely affect the safety case for TASAR and would actually serve to 
mitigate a TASAR processing failure by increasing the pilot’s situational awareness and ability to detect such a 
failure. As noted, TAP does not depict own-ship position on the TASAR display, whether textually or graphically, 
which avoids a potential issue with regard to Failure Effects Classification of a Type C software application that 
displays own-ship on an airport map display. 6 

IV. Operational Safety Assessment 

For TASAR to be a viable, near-term option for users, the concept must not only achieve a positive benefit-to- 
cost business case, but its design should have a relatively low threshold for achieving certification and operational 
approval from the FAA. The certification and operational approval of any new airborne equipment or capability 
will be subject to an FAA review of the operational hazards and safety of the application. To qualify as a Class 2 
EFB application with Type B software, the airborne function must be determined to have a Failure Effects 
Classification of no greater than “Minor” effect due to potential hazards. Elements relevant to an operational safety 
analysis of TASAR were examined 10 using abbreviated application of established safety assessment 
methodologies . 1 1 ' 14 

A. Intended Function 

Key to the safety analysis is an understanding of the application’s intended function. TASAR’s intended 
function is to provide an advisory-only service to the pilot by identifying trajectory improvement opportunities over 
the current flight plan that have increased likelihood of ATC approval. Based on inputs provided by the pilot (in the 
form of flight optimization criteria and constraints), on-board avionics systems, and external data sources via ADS- 
B IN and airborne internet connectivity, the TASAR application computes available change request candidates that 
may improve flight time, fuel burn, or some other specified attribute. Change request candidates provided by 
TASAR are expected to have relatively high probability of ATC approval, as it anticipates ATC constraints such as 
traffic conflicts and airspace boundaries in the generation of optimization candidate solutions. 

B. Framing the Safety Case 

A review of TASAR’s inherent design characteristics can help to put the safety case in context. The TASAR 
system is only a supplemental, recommendation-generating system. It is not relied on for any critical functions 
supporting flight operations, and it should not be included on the aircraft’s Minimum Equipment List. Its use is 
entirely optional, and it can be disabled or ignored without any adverse effects and for any reason, whether for a 
failure of the TASAR software or the EFB hardware, spurious or inconsistent trajectory-change recommendations, 
or if the aircrew finds it distracting. The TASAR concept makes no changes to pilot or controller responsibilities 
nor to their interchange on trajectory change requests, and so loss or failure of TASAR advisories have no effect on 
either the pilot or controller in performing their normal functions. These factors provide significant mitigations that 
greatly reduce the risks associated with failures of the TASAR system. 

C. Operational Hazards and External Mitigation 

An analysis identified potential sources for errors and misleading information stemming from information 
exchanges and TASAR automation processing actions. For example, own-ship or traffic information that are 
incorrect or incomplete could lead to TASAR change request candidates that have a conflict, but are presented as 
conflict free. In another example, incorrect information on winds or weather hazards could lead to TASAR change 
request candidates that lead into hazardous weather. A complete list of identified hazards is included in Reference 
10. Any incorrect information provided to TASAR or errors/failures in TASAR automation processing could 
potentially result in misleading change request candidates being recommended to the pilot for consideration. Such 
misleading information may detract from the usability of TASAR to achieve operational benefits (i.e., time or fuel 
saved) and could result in additional workload from pilot troubleshooting. However, since the flight crew has no 
authority to deviate from their current ATC clearance, regardless of the information provided by TASAR, any 
occurrence of misleading information from TASAR will be non-hazardous in nature and is completely mitigated by 
the existing ATC clearance procedure. 

Furthermore, the pilot has responsibility to evaluate TASAR -provided trajectory change request candidates 
before making a change request to ATC, providing cross-check opportunities to detect spurious or false trajectory 
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change request candidates being offered by TASAR. In addition, certified aircraft systems (e.g., FMS, weather 
radar) serve as higher integrity information sources to check on acceptability and performance impacts of TASAR - 
recommended change requests. In the event of an undetected failure of the TASAR automation, inefficient routing 
is the only adverse outcome. Existing mitigation of any safety hazards is provided by ATC, as already is done for 
change requests today without TASAR, and by normal pilot procedures for safe operation of the aircraft (e.g., 
avoiding hazardous weather). 

D. Internal Mitigations 

The TASAR application itself can include additional inherent design factors that would further reduce the 
possibility of unintended adverse effects and are expected to enhance the usability of the application. For instance, 
the use of standard navigation databases and limits placed on the number of included waypoints would prevent 
lengthy, complex change requests that may lead to miscommunication or errors. Recommendations displayed using 
standard flight planning textual depictions would further facilitate expedited voice communications. TASAR 
applications may also include capabilities to assess sector complexity and own-ship’s proximity to the sector 
boundary in order to only recommend change requests that have a high likelihood of being approved by ATC. 

An important characteristic of TASAR is that there is no “recovery” time required for the flight crew associated 
with its discontinued use. In other words, in using TASAR, the pilot remains on an ATC-cleared trajectory at all 
times. In the event of a TASAR system fault, the pilot need only remain on the current clearance while disregarding 
the TASAR display. A simple reset of TASAR, or by simply choosing to ignore TASAR inputs (e.g., by not 
looking at the TASAR display) allows the pilot to continue to focus on flight operations (whether during normal 
operations or in the event of abnormal or emergency situations). 

E. Probable Failure Effects Classification 

Table 1 is derived from FAA Advisory Circular 25.1309-1A “System Design and Analysis” 13 and provides a 
mapping of the “Effects” due to failures and the allowable “Probability of Occurrence” that lead to the determination 
of the Failure Effects Classification of the planned application (i.e., TASAR). Based on the significant mitigation 
factors already identified above that are inherent to TASAR, the analysis concluded that TASAR can be safely 
developed and implemented with a “No Effect” or at most a “Minor Effect” designation. If needed, the latter 
designation would reflect any workload issues for the pilot or ATC due to inconsistent or erroneous change request 
recommendation(s). However, workload issues are not anticipated to be an issue for the pilot’s use of TASAR, as 
the pilot can simply ignore TASAR for any reason. Through proper training in the use of TASAR, the pilot should 
not be distracted or be adversely influenced in using TASAR while conducting flight operations. From an ATC 
perspective, controllers will continue to conduct the change request process as in today’s operation and are not 
expected to experience a workload issue due to TASAR. 

Final determination of the Failure Effects Classification for TASAR will require a dialog between the applicant 
and FAA Certification and Operational Approval authorities using the results of the safety analysis, which will result 
in a final designation by the FAA. 

Table 1 Acceptable Risk versus Potential Effects as defined for Civil Aviation.13 TASAR focus area is boxed. 


Probability (Quantitative) 
[Not to Exceed] 

1 

lO' 3 

10~ 5 

10' 7 

10‘ 9 

Probability Descriptive 

N/A 

Probable 

Improbable 

Extremely Improbable 

Failure Condition Hazard 
Severity Classification 

None 

Minor 

Major 

Hazardous/ 
Severe Major 

Catastrophic 

Effects on Aircraft and 
Occupants 

• No 
Safety 
Effect 

• Does not significantly reduce 
airplane safety (slight increase in 
safety margins) 

• Crew actions well within 
capabilities 

(slight increase in crew workload) 

• Some inconvenience to occupants 

• Reduce capability of airplane or crew to 
cope with adverse operating conditions 

• Significant reduction in safety margins 

• Significant increase in crew workload 

Severe Cases: 

• Large reduction in safety margins 

• Higher workload or physical distress on 
crew - can't be relied upon to perform 
tasks accurately 

• Adverse effects on occupants 

• Conditions which prevent 
continued safe flight and 
landing 

System Design Assurance 
Level (DAL) 

E 

D 

C 

B 

A 
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V. Accessing Required Data 

A technical challenge facing TASAR is the application’s access to the data required to perform its intended 
function, advising aircrews of traffic compatible trajectory changes that improve operator objectives including fuel 
burn and flight time. An analysis was conducted for the NASA prototype application, TAP, regarding its access to 
the required data. At its core, the TAP application provides a route-replanning capability that optimizes the 
aircraft’s future trajectory based on fuel and/or time. This route-replanning capability requires the TAP application 
to know a wide variety of information regarding the own-ship aircraft, including its current state (e.g., position, 
altitude, speed, weight), guidance modes (lateral, vertical, speed), guidance settings (e.g., FMS active route), and 
performance limits (e.g., maximum cruise altitude). To perform fuel burn and flight time optimization during route - 
replanning, the TAP application also needs to have a model of atmospheric conditions (winds, temperature, and 
pressure aloft). The TAP application integrates its route -replanning capability with a conflict probe to assess the 
compatibility of a proposed route change with traffic aircraft and airspace constraints (e.g., convective weather. 
Special Activity Airspace (SAA)). This conflict probe requires knowledge of traffic aircraft states, airspace 
geometries, SAA activation schedules, convective weather, and other airspace restrictions and hazards to determine 
if an auto-generated or pilot-input trajectory change request would be unacceptable to a controller. 

As a cockpit-based system, the TAP application’s primary sources for its required data are the avionics systems 
onboard the own-ship aircraft. Avionics data are shared among the aircraft’s various avionics systems via a data bus 
that follows the ARINC 429 specification. Class 2 EFB applications can indirectly access this data bus via a certified 
aircraft interface device (AID). An AID reads ARINC 429 data from the data bus and provides this data to EFB 
applications following the Simple Text Avionics Protocol (STAP) defined in ARINC Specification 834. 

A secondary source of data for the TAP application is via the aircraft’s broadband internet capability. The TAP 
application only uses secondary sources, such as broadband internet, if the required data are not available from the 
primary avionics systems sources. As can be imagined, access to the internet from the cockpit allows access to a 
wide range of additional data sources. 

In preparation for TASAR in-flight assessments, the TAP application has been integrated with the systems 
onboard a Piaggio Avanti I aircraft equipped with ADS-B IN and broadband internet connectivity. The Piaggio is a 
general aviation aircraft, and as such, outputs from its avionics systems follow the General Aviation Manufacturers 
Association (GAMA) General Aviation ARINC 429 subset. The challenges experienced in gaining access to TAP- 
required data onboard the Piaggio illustrate several challenges expected when integrating the TAP application with a 
wider range of aircraft types in the future. The Boeing 737NG series and Airbus 320 are the primary aircraft types 
serving the United States (US) domestic airlines, and therefore considerations for adapting TAP to these aircraft 
were taken into account in this analysis. The following subsection presents a discussion of the own-ship avionics as 
the primary data source. The subsequent subsection discusses broadband internet as a secondary data source. 

A. Own-ship Avionics as the Primary Data Source 

For an application on the EFB to receive data via an AID, the ARINC 429 outputs of various avionics systems 
need to be assigned to the input ports of the AID. For the Piaggio, the following avionics outputs were made 
available and are used by the TAP application: 

• Flight Management System (FMS) 

• Inertial Reference Unit (IRU) 

• Global Positioning System (GPS) 

• Air Data Computer (ADC) 

• ADS-B Receiver 

• Electronic Flight Instrument System (EFIS) 

Own-ship State Data 

Own-ship state data are provided to TAP by the FMS, ADC, and IRU systems; Universal Time Coordinated 
(UTC) data are provided by the GPS; guidance mode information is provided by the EFIS; FMS active route data 
are provided by the FMS; and traffic state data are provided by the ADS-B receiver. 

Not all of the required own-ship state data are available from the AID. For example, the aircraft’s current gross 
weight is required but unavailable in the GAMA ARINC 429 subset. Gross weight is used by TAP to accurately 
predict the aircraft’s future trajectory, especially in climb and descent phases of flight. Though the TAP application 
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can still advise aircrews of traffic compatible route changes by using default or aircrew-specified weight values, this 
situation does highlight a challenge for the TAP application. Manual crew inputs to the TAP user interface can be 
used to enter information, but this may detract from TASAR’s usability. To minimize crew workload, the TASAR 
concept has a design goal to receive as much information as possible through direct interfaces with the aircraft 
systems. Because avionics systems are not required to provide all of the data included in the ARINC 429 
specification, some level of customization of the TAP application for a specific aircraft platform is to be expected. 
Systems may also provide data in a format outside of the ARINC 429 specification. For example, the GAMA 
ARINC 429 subset conflicts with ARINC 429 in that the 075 label used for Gross Weight from the FMS in ARINC 
429 is used for active route data from the FMS in the GAMA subset. The current TAP application is being 
architected to make customization as straight forward as possible for new aircraft platforms. 

Own-ship Active Route Data 

The receipt of active route data from the FMS also provides a significant general challenge for the TAP 
application. For late model B737 and A320 aircraft, FMS intent information is provided to the aircraft’s data bus 
using the ARINC Characteristic 702A-1 standard. TAP requires own-ship active route information, including lateral, 
altitude and speed constraints, to generate effective route changes and to accurately predict the flight time and fuel 
burn for these changes in support of its route replanning capability. Unfortunately, the current specifications for 
active routes under ARINC 429 are focused either on providing 4-dimensional (4D) predictions of the aircraft path 
based on the active route (702A-1) or on providing primarily lateral route information for cockpit displays (GAMA 
General Aviation Subset). Hence, required route constraint data may be unavailable from these systems. For 
example, neither 702A-1 nor GAMA provides the current cruise altitude for the active route. These limitations have 
the potential to impact TASAR concept feasibility, so they were investigated as part of the application design. An 
analysis of the TAP trajectory generation (TG) function and currently available data from aircraft systems found that 
there is enough information for TAP to predict own-ship trajectories without additional pilot inputs. To do this, a 
few default values based on rational assumptions are used. Providing correct data will result in more accurate 
trajectory predictions. For instance, if the aircraft is near top-of-descent, the pilot may need to enter additional 
information such as altitude constraints in descent to increase trajectory prediction accuracy. Additional approaches 
to calculating approximations to unavailable active route data are also under investigation. For example, a good 
approximation for most level-flight cruise situations is to assume that the current own-ship altitude is the cruise 
altitude. In another example, whereas trajectory change point identifier information is not provided by the 702A-1 
standard, latitude and longitude information can be used to identify waypoint names from a database. 

Further investigations may find that improved trajectory predictions are not necessary. Because TAP advisories 
are based on trajectory changes rather than absolute values, a portion of the trajectory prediction errors, and hence 
the optimization parameter (e.g., time, fuel) estimate errors, are removed. The TG function used in the initial TAP 
application is of the same level of sophistication as an FMS TG function. Further research may find that a lower 
level of sophistication is fully acceptable for the TASAR concept. For the above reasons, the risk in concept 
feasibility due to limitations in obtaining own-ship data from current aircraft systems is believed to be manageable. 
Over time, new standards may allow a more complete set of internal FMS data to be available to the aircraft data 
bus. This will further improve the accuracy of TAP optimization values. 

Atmospheric Data 

Wind, pressure, and temperature at the aircraft’s current position and altitude are available to the aircraft’s 
avionics systems, but they are inadequate for TAP route-replanning. The TAP application needs atmospheric data 
for a broad geographic scope covering all alternative routes that the TAP application will consider. TAP has the 
capability to utilize 4D gridded wind and temperature fields if such data can be provided. Currently, the only 
avionics system that has atmospheric data beyond the aircraft’s current position is the FMS, but even if these data 
were readily available through the aircraft data bus (it is not for the Piaggio), the atmospheric modeling data within 
the FMS is limited. For example, for the Boeing 737 FMS, climb and descent winds are entered for only three 
altitudes and are not related to a specific lateral location. 15 For the cruise portion of the flight, a single wind value 
can be entered for each lateral waypoint in the active route, or alternatively, a single average wind value for the 
entire cruise phase can be entered. Temperature data are similarly limited. Since atmospheric modeling has a 
significant impact on the performance of the route -replanning capability, alternative atmospheric data available from 
secondary data sources that cover a broader geographic scope (see next subsection) is likely to be preferable. 
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Traffic and Airspace Hazard Data 

Hazard information is a key element of the TASAR concept, and current avionics can support the identification 
of traffic and airspace hazards. For traffic aircraft, the data received from the ADS-B receiver via the AID follow the 
ARINC Characteristic 735B and are sufficient to define the current state of 128 traffic aircraft within ADS-B range. 
Traffic data for display systems is available to TAP in the Display Traffic Information Files (DTIF) format. Though 
TAP can handle and would benefit from additional ADS-B reports regarding the intent of the traffic aircraft (ADS-B 
target state or trajectory change reports, as defined in the Minimum Aviation System Performance Standards), there 
is currently no ARINC specification for these additional ADS-B reports. For special use and other restricted 
airspace, the airspace boundaries are available to TAP via its internal database, which conforms to the ARINC 424 
Specification. What is not available to TAP from the database or other avionics systems is the schedule for when the 
airspace is available. This information could be entered manually by the user, but alternative sources (see next 
subsection) are preferred. For convective weather hazards, one desired source for these data is the onboard weather 
radar. Unfortunately, these data are not readily available to the Piaggio’s AID. Even if onboard weather radar data is 
available on other aircraft platforms, it is expected that more strategic convective weather data sources (see next 
subsection) would still be desired in addition to the onboard weather radar to enable assessing route change 
compatibility with potential convective weather hazards at larger distances than can be supported solely by onboard 
weather radar data. 

B. Broadband Internet as a Secondary Data Source 

TASAR automation can leverage onboard broadband internet to provide supplemental traffic state and intent 
data, atmospheric conditions, airspace restrictions, and any other data source available over the internet. Internet 
data sources could have higher resolution, broader geographic scope, and longer forecast horizons than other 
potential data sources such as Flight Information Service-Broadcast (FIS-B), ADS-B, Traffic Information Service- 
Broadcast (TIS-B), satellite weather service, or onboard weather radar. Broadband internet is currently available to 
aircraft through a cell-tower based service and a satellite -based service that are available throughout the continental 
US where the initial deployment of TASAR is targeted. Maximum bandwidth can vary depending on the 
characteristics of the broadband system and the size and power characteristics of the on-board antenna. On the 
Piaggio aircraft, a low-gain satellite broadband antenna (11 in., 1.5 lbs.) was installed to accommodate size and 
placement restrictions. The maximum bandwidth of this low-gain antenna is 200 kbps, which is approximately 
1/1 5 th of the current typical maximum bandwidth of cell-tower based internet on commercial aircraft (3 Mbps). 
Broadband may be provided to the TAP EFB platform via an Ethernet or wired connection using standard internet 
protocols. 

Traffic Data 

ADS-B IN is envisioned to be the primary source of traffic state data for computing traffic -compatible trajectory 
changes. However, not all aircraft will (1) be equipped with ADS-B OUT prior to the 2020 ADS-B mandate, (2) 
broadcast ADS-B on a channel (1090 MHz Extended Squitter or 978 MHz Universal Access Transceiver) that can 
be received by the own-ship ADS-B IN system, or (3) be within ADS-B reception range of the own-ship. This 
would cause TASAR to have incomplete surveillance when exclusively leveraging ADS-B. Although complete 
surveillance is not required for users to benefit from TASAR 4 , the closer the TASAR automation and ATC’s view of 
the traffic situation are to each other, the more requests will likely be traffic compatible and approved. TIS-B 
broadcasts surveillance data to equipped aircraft and can be used to provide more complete traffic surveillance of 
target aircraft that are not equipped with ADS-B OUT. However, TIS-B provides limited traffic information and is 
best suited as a complementary data source. For example, TIS-B is filtered so that aircraft not equipped with ADS-B 
OUT beyond 15 nmi of the own-ship or above or below the own-ship by more than 3,000 ft will not be broadcasted 
through TIS-B. Another limitation is that TIS-B has a service ceiling so that the own-ship will not receive any traffic 
information at some point at or above 24,000 ft. 

Traffic data available over the internet can be used to overcome incomplete ADS-B OUT equipage, ADS-B and 
TIS-B reception range, and lack of intent (planned trajectories) in the ADS-B reports. The Aircraft Situation Display 
to Industry (ASDI) is one source of surveillance data that the FAA provides to subscribers to increase situational 
awareness. ASDI combines radar, ADS-B, and flight plan information from across the NAS into a single source of 
surveillance data. ASDI provides position and planned route data to subscribers, which are generally flight operators 
with dispatching responsibilities. The following four limitations would need to be addressed before TASAR uses 
ASDI data, possibly by the flight operator providing a ground system that filters and processes ASDI data before 
being sent via broadband to TASAR. (1) A security audit of each TASAR instance would need to be performed if 
receiving data directly from the FAA as well as providing a static internet protocol (IP) address for each TASAR 
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instance. The security audit and static IP would not be required if a flight operator rebroadcast their existing ASDI 
feed to the aircraft. (2) ASDI could consume a significant portion of bandwidth for low-gain antenna systems such 
as that used by the Piaggio. This issue could be mitigated if a flight operator leveraged a ground system to filter 
ASDI data by geographic scope, remove data fields that TASAR does not require, and compress the ASDI data 
before being sent to TASAR. (3) Flight plans and amendments are only broadcast once (unless modified) so the 
receiving system must be continuously online to receive all ASDI messages. Otherwise, only a subset of flight plan 
and amendment messages will be available to TASAR. A ground system that maintains a list of flight plans and 
amendments for airborne flights could be used to overcome this limitation. (4) ASDI provides information at a 
slower update rate (one update per minute) as compared to TIS-B (at least five updates received per minute) and 
ADS-B (at least ten updates per minute). Additionally, ASDI data could be delayed up to five minutes. This data 
latency and slower updates may need compensation by TASAR algorithms. 

Weather Data 

Broadband internet could be used as a source of convective weather for TASAR if FIS-B, satellite weather, 
and/or onboard weather radar data are not available to the TASAR automation. FIS-B may not be available above a 
24,000 ft service ceiling or may not provide the right data source that has a suitable resolution for route -replanning 
while also being suitably broad in geographic scope. Satellite weather provides convective weather in a proprietary 
format that would need to be made available to TASAR application developers. Onboard weather radar data are sent 
directly to a display in the Piaggio and are not available to TASAR as discussed in the previous subsection. If these 
data sources are unavailable or unsuitable, then broadband internet could be used to access a source of convective 
weather over the internet (e.g.. National Convective Weather Forecast) that is suitably broad in geographic scope to 
cover the range of alternative trajectories considered by TAP. Initial feedback from subject matter experts suggest 
that TAP may need to incorporate user control of the severity threshold for convective weather that TAP should 
avoid when developing alternative trajectories. 

Atmospheric Data 

Winds and temperature aloft for a range of altitudes and a broad geographic scope covering all alternative 
waypoints considered by TAP are needed to evaluate trajectories against operator objectives including fuel burn and 
flight time. FIS-B and satellite weather provide this information, but with limitations similar to that described above 
for convective weather. Rapid Refresh (RAP) 16 " 18 is one source of winds and temperature data in gridded binary 
(GRIB) format that covers the continental US at a range of altitudes. A course RAP grid resolution (e.g., 40 km) can 
be selected to minimize bandwidth with finer resolutions (e.g., 13 km) available if bandwidth permits. 

Airspace Data 

SAA activation schedules. Notice to Airmen (NOTAM), temporary flight restrictions (TFRs), pilot reports 
(PIREPS), and other similar data sources can be used by TASAR automation to identify regions of airspace 
unavailable for trajectory planning. These data are all available over broadband from FAA websites and other 
sources. FIS-B and satellite weather, if available, could also be a source of this information. 

VI. Conclusion 

NASA’s research and development activities to date on the TASAR concept have focused on proof-of-concept 
and risk reduction for potential users. A design goal for the TASAR concept and its enabling flight deck technology 
has been to provide direct user benefits at low cost, for near-term implementation, and with low operational approval 
risk. NASA has assessed potential benefits, investigated implementation with currently operating aircraft and 
currently-available data sources, and determined the likelihood of technical certification and operational approval. 

TASAR has been found to provide user benefits only with an EFB equipment investment. Users opting to 
leverage ADS-B IN equipment and additional data sources (e.g., satellite weather, broadband internet) can expect an 
increase in user benefits. TASAR also leverages the aircrew workforce, whose workload en route is typically low, 
and thus requires no additional ground personnel or extra workload on the dispatcher. 

NASA has developed a prototype software application for TASAR called the “Traffic Aware Planner” (TAP) 
with the intent of making it available to users and technology providers. An analysis of TAP compatibility with 
operational flight deck systems has determined that the minimum required data for the TAP algorithms are 
accessible from standard ARINC 429 data for late-model transport and business aircraft. Additional data that will 
provide increased user benefits may become available through broadband internet sources in the near future. 
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An analysis of FAA regulatory material confirmed that a Class 2 PED/EFB provides a well -suited, low-cost 
platform for TASAR, and that the software falls below the criticality level of most Type B applications. An analysis 
of hazards and safety requirements determined that TASAR would likely receive a Failure Effects Classification of 
“no effect” or at most “minor effect.” A draft Project Specific Certification Plan was developed and reviewed by 
Designated Engineering Representatives with no concerns raised. 

Finally, during the summer of 2013, TAP is being tested by airline pilots in high-fidelity simulation and in a 
flight test aircraft operating in ATC-controlled airspace using real-world data flows. The concept, development, 
analyses, and test results are being documented and will be made available as artifacts to support initial applicants in 
the FAA approval process. 
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